Skip to main content

Workflow de développement Git : GitFlow

⚠️ ce workflow est détaillé dans les pratiques NCIT NCIT-IT-ARCH-Workflow Git.pptx. Vous pouvez retrouver ici des écarts spécifiques uniquement pour ce projet, mentionnés comme tels.

Une stratégie de branchement GitFlow est adoptée pour structurer le travail de développement.

image.png Principe généraux de Gitflow (le nom des branches peut ne pas être correct)

Branches Principales​

  • master : Reflète l'état de la production. Protégée contre les pushs directs sans PR. Les mises en production se font par PR de merge depuis la branche staging uniquement.
  • staging : Branche d'intégration principale. Reflète l'état de la prochaine version.
  • develop (ou dev) : Branche d'intégration principale. Reflète l'état de la prochaine version.

Branches de Travail​

> Note : les branches de travail seront créés sur les environnement de développement local des postes des développeurs. Les branches en cours de développement qui ne sont pas fusionnés dans la journée devront être envoyé sur le serveur Git remote pour sauvegarde, puis supprimer par son propriétaire une fois le merge réalisé dans les branches principales ou perpétuelles.

Branches éphémères :

  • Features : feat/TICKET-123-creation-actualites. Chaque nouvelle fonctionnalité ou modification est développée dans sa propre branche, nommée d'après le ticket correspondant.
  • Bug Fixes : fix/456-fix-formulaire-contact OU bugfix/456-fix-formulaire-contact. Créée depuis « develop» pour les corrections non urgentes, qui suivent la chaine de validation des environnements.
  • Hot fixes : hotfix/456-fix-formulaire-contact. Créée depuis « master » pour les corrections urgentes en production.

Branches perpétuelles :

  • Releases : release/v20250811. Créée depuis « staging » pour préparer une mise en production (tests finaux, corrections mineures).

Politique de PR​

  • master : PR obligatoire, validation d'un autre reviewer obligatoire (peut être la même personne dans un premier temps pour éviter situation de blocage, notamment en permettant de gérer le cas d'un hotfix sur la master quand même).
  • staging : PR obligatoire, validation d'un autre reviewer obligatoire. Tagging de la version CalVer à chaque PR.
  • develop : PR obligatoire, pas de validation d'un reviewer.

Politique de Commit​

  • Les messages de commit doivent suivre la spécification Conventional Commits.
  • Format : type(scope): description (ex: feat(actualite): ajoute le champ épingler).
  • Types : feat, fix, docs, style, refactor, test, chore.
  • Bénéfices : Historique Git clair, génération automatique de changelogs.

Fichier .gitignore​

  • Un fichier .gitignore complet est essentiel. Il doit exclure :
    • Les dépendances gérées par Composer : /vendor/, /web/core/, /web/modules/contrib/.
    • Les fichiers générés par l'utilisateur : /web/sites/default/files/.
    • Les assets compilés : /web/themes/custom/cam_theme/css/, /web/themes/custom/cam_theme/js/.
    • Les dépendances Node.js : /web/themes/custom/cam_theme/node_modules/.
    • Les fichiers de configuration locaux : /web/sites/default/settings.local.php.

Environnement de Développement Local avec Docker​

Pour garantir que tous les développeurs travaillent sur un environnement identique à celui de la production, Docker et Docker Compose seront utilisés. Voir README pour le déploiement ou la documentation associés dans le wiki ou le répertoire /docs des sources.